The following contributors got their Debian Developer accounts in the last two months:
The following contributors were added as Debian Maintainers in the last two months:
Just over 7 months ago, I
blogged
about extrepo, my answer to the
"how do you safely install software on Debian without downloading random
scripts off the Internet and running them as root" question. I also held
a
talk
during the recent "MiniDebConf Online" that was held, well, online.
The most important part of extrepo is "what can you install through it".
If the number of available repositories is too low, there's really no
reason to use it. So, I thought, let's look what we have after 7
months...
To cut to the chase, there's a bunch of interesting content there, although not all of it has a "main" policy. Each of these can be enabled by installing extrepo, and then running extrepo enable <reponame>, where <reponame> is the name of the repository.
Note that the list is not exhaustive, but I intend to show that even though we're nowhere near complete, extrepo is already quite useful in its current state:
debian_official, debian_backports, and debian_experimental repositories contain Debian's official, backports, and experimental repositories, respectively. These shouldn't have to be managed through extrepo, but then again it might be useful for someone, so I decided to just add them anyway. The config here uses the deb.debian.org alias for CDN-backed package mirrors.belgium_eid repository contains the Belgian eID software. Obviously this is added, since I'm upstream for eID, and as such it was a large motivating factor for me to actually write extrepo in the first place.elastic: the elasticsearch software.dovecot, winehq and bareos
contain upstream versions of their respective software. These two repositories contain software that is available in Debian, too; but their upstreams package their most recent release independently, and some people might prefer to run those instead.sury, fai, and postgresql repositories, as well as a number of repositories such as openstack_rocky, openstack_train, haproxy-1.5 and haproxy-2.0 (there are more) contain more recent versions of software packaged in Debian already by the same maintainer of that package repository. For the sury repository, that is PHP; for the others, the name should give it away.
The difference between these repositories and the ones above is that it is the official Debian maintainer for the same software who maintains the repository, which is not the case for the others.vscodium repository contains the unencumbered version of Microsoft's Visual Studio Code; i.e., the codium version of Visual Studio Code is to code as the chromium browser is to chrome: it is a build of the same softare, but without the non-free bits that make code not entirely Free Software.extrepo, too. The iridiumbrowser repository contains a Chromium-based browser that focuses on privacy.torproject repository.kubernetes repository that contains the Kubernetes stack, the as well as the google_cloud one containing the Google Cloud SDK.extrepo, please note that non-free and contrib repositories are disabled by default. In order to enable these repositories, you must first enable them; this can be accomplished through /etc/extrepo/config.yaml.
vscode repository contains it.msteams repository. And, hey, skype.opera and google_chrome.docker-ce repository contains the official build of Docker CE. While this is the free "community edition" that should have free licenses, I could not find a licensing statement anywhere, and therefore I'm not 100% sure whether this repository is actually free software. For that reason, it is currently marked as a non-free one. Merge Requests for rectifying that from someone with more information on the actual licensing situation of Docker CE would be welcome...steam repository.
I joined the
Debian project in late 1994, well before the first
stable release was issued, and have been involved in various ways continuously
ever since. Over the years, I adopted a number of packages that are, or at
least were at one time, fundamental to the distribution.
But, not surprisingly, my interests have shifted over time. In the more than
quarter century I've contributed to Debian, I've adopted existing packages
that needed attention, packaged new software I wanted to use that wasn't yet
in Debian, offered packages up for others to adopt, and even sometimes
requested the removal of packages that became obsolete or replaced by
something better. That all felt completely healthy.
But over the last couple weeks, I realized I'm still "responsible" for some
packages I'd had for a very long time, that generally work well but over time
have accumulated bugs in functionality I just don't use, and frankly haven't
been able to find the motivation to chase down. As one example, I just
noticed that I first uploaded the gzip package 25 years ago today, on
2 December 1995. And while the package works fine for me and most other
folks, there are 30 outstanding bugs and 3 forwarded bugs that I just can't
muster up any energy to address.
So, I just added gzip to a short list of packages I've offered up for
adoption recently. I'm pleased that tar already has a new maintainer, and
hope that both sudo and gzip will get more attention soon.
It's not that I'm less interested in Debian. I've just been busy recently
packaging up more software I use or want to use in designing high
power model
rockets and the solid propellant motors I fly in them, and would rather spend
the time I have available for Debian maintaining those packages and all their
various build dependencies than continuing to be responsible for core
packages in the distribution that "work fine for me" but could use attention.
I'm writing about this partly to mark the passing of more than a quarter
century as a package maintainer for Debian, partly to encourage other Debian
package maintainers with the right skills and motivation to consider adopting
some of the packages I'm giving up, and finally to encourage other long-time
participants in Debian to spend a little time evaluating their own package
lists in a similar way.
Another month worth of updates on KDE/Plasma in Debian has accumulated, so here we go. The highlights are: Plasma 5.19.5 based on Qt 5.15 is in Debian/unstable and testing, Plasma 5.20.4 is waiting to be uploaded soon to experimental, and my own builds at OBS have been updated to Plasma 5.20.4, Frameworks 5.76, Apps 20.08.3.
OBS packages
The OBS packages as usual follow the latest release, and currently ship KDE Frameworks 5.76, KDE Apps 20.08.3, and new, Plasma 5.20.4. The package sources are as usual (only the other-dep has disappeared, these packages are now all in Debian proper), for Debian/unstable:
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma520/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2008/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/Debian_Unstable/ ./
Testing instead of Unstable for Debian/testing.
The latest update to 5.20.4 will probably need one or two install cycles due to missing Replaces. The reason is that the packages in OBS have been synced with the work we have done for the official Debian packages, and thus some files have moved between packages.
Debian main packages
After a few hiccups, the whole Plasma 5.19.5 stack has landed in Debian/testing, and we are working on an upload of 5.20.4 to Debian/experimental. This takes a bit, because we want to add infrastructure to automatically force all packages to be upgraded only together, so that there is no mix between old and new packages. This has shown quite some problems during the upgrade from 5.17 to 5.19 in testing. Also, I don t think Debian needs to do something else than everybody else by allowing to mix Plasma released.
That said, I hope that we have an upload of 5.20 to experimental soon, followed by testing and an upload to unstable, so that it can migrate to testing in time for the freeze of Bullseye. Getting 5.20.5 into Bullseye is possible, but not guaranteed, not too much time between the release of 5.20.5 and proper freeze in Debian. But we will see.
Enjoy.
The following contributors got their Debian Developer accounts in the last two months:
About a month worth of updates on KDE/Plasma in Debian has accumulated, so here we go. The highlights are: Plasma 5.19.5 based on Qt 5.15 is in Debian/experimental and hopefully soon in Debian/unstable, and my own builds at OBS have been updated to Plasma 5.20.2, Frameworks 5.75, Apps 20.08.2.
Thanks to the dedicated work of the Qt maintainers, Qt 5.15 has finally entered Debian/unstable and we can finally target Plasma 5.20.
OBS packages
The OBS packages as usual follow the latest release, and currently ship KDE Frameworks 5.75, KDE Apps 20.08.2, and new, Plasma 5.20.2. The package sources are as usual (note the different path for the Plasma packages and the App packages, containing the release version!), for Debian/unstable:
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma520/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2008/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/Debian_Unstable/ ./
Testing instead of Unstable for Debian/testing.
The update to Plasma 5.20 took a bit of time, not only because of the wait for Qt 5.15, but also because I couldn t get it running on my desktop, only in the VM. It turned out that the Plasmoid Event Calendar needed an update, and the old version crashed Plasma ( v68 and below crash in Arch after the Qt 5.15.1 update. ). After I realized that, it was only a question of updating to get Plasma 5.20 running.
There are two points I have to mention (and I will fix sooner or later):
Welcome to gambaru.de. Here is my monthly report (+ the first week in October) that covers what I have been doing for Debian. If you re interested in Java, Games and LTS topics, this might be interesting for you.
Debian Games
Update 2020-10-19: All packages are now available in Debian/experimental!
More than a month has passed since my last KDE/Plasma for Debian update, but things are progressing nicely.
OBS packages
On the OBS side, I have updated the KDE Apps to 20.08.2, and the KDE Frameworks to 5.75. Especially the update of apps brings in at least a critical security fix.
Concerning the soon to be released Plasma 5.20, packages are more or less ready, but as reported here we have to wait for Qt 5.15 to be uploaded to unstable, which is also planned in the near future.
Debian main packages
Uploads of Plasma 5.19.4 to Debian/experimental are processing nicely, more than half the packages are already done, and the rest is ready to go. What holds us back is the NEW queue, as usual.
We (Scarlett, Patrick, me) hope to have everything through NEW and in experimental as soon as possible, followed by an upload of probably Plasma 5.19.5 to Debian/unstable.
Thanks also to Lisandro for accepting me into the Salsa Qt/KDE team.
trace-cmd for Sudip, ruby-asset-sync for Nilesh, and mariadb-mysql-kbs for William.
This Google Summer of Code, I worked on writing a linter that could flag offenses for lines of code
that are very troublesome for Debian maintainers while trying to package and maintain Ruby libraries and applications!
Whilst the GSoC period is over, I ve been working on improving that tool and have extended that linter to now auto-correct these offenses
by itself! \o/-A flag and you re done! Boom! The ultimate game-changer!
Here s a quick demo for this feature:
A few quick updates on RuboCop::Packaging:
-A flag.
mktemp instead of tempfile in bin/auto-add-end-of-life.sh.:wq for today.
The following contributors were added as Debian Maintainers in the last two months:
The following contributors got their Debian Developer accounts in the last two months:
In May 2020, I have worked on the Debian LTS project for 14.5 hours (of 14.5 hours planned).
LTS Work
The following contributors got their Debian Developer accounts in the last two months:
Since many years I am a big big fan of Unison. It is a two-way synchronization tool, meaning that changes on both sides are carried over as long as there is no conflict. Unison is the bread and butter for keeping my computers (main desktop, laptop, server) in sync. There is only one problem with Unison it is extremely picky about with what kind of Unison on the other side it speaks: Even the very same version, compiled with a slightly different OCaml compiler version, already produces incompatibilities. And with me having to sync between Debian/Buster (my server) and Debian/sid (my other machines), this always ended in tears. But heyhoh! the pain is over!
My solution up to now was to keep a Unison binary from Buster on my Sid system, and used that binary when syncing to Buster server, but the normal Unison binary when syncing between two sid computers. This created lots of pain, because, when using a incompatible Unison binary, already a simple connect without a sync trial messed up the state files and required a complete resync. And so it happened often that I used the wrong binary, and had to resync a few gigabyte, what a pain.
The Debian maintainer is working with upstream to improve this rather unfortunate situation, so maybe this will change in the future, but I need a solution now. BTW, thanks a lot to the excellent work of the current maintainers, setting up the new package was a blaze and only needed a bit of adjustments for the changed layout of recent sources. Big kudos to the maintainers of unison!!!
So I have ventured out to create my own Unison package for Debian. And what I mean for Debian/Buster and Debian/sid, so that they are compatible, by using the very same compiler and the very same source and the very same dependencies to build the binaries. Fortunately, the lessons learned from my KDE/Plasma updates for Debian helped, and with a bit of magic and the nice service from the openSUSE build service, I now have packages for Unison ready for Debian/Buster and Debian/sid that are compatible, and in addition also the latest version, not the 5 year old package that is currently Debian.
So here it is, the Debian Unison repository, binaries of (currently) Unison 2.51.2 are available for both i386 and amd64:
For Debian/Buster
deb http://download.opensuse.org/repositories/home:/npreining:/debian-unison/Debian_10 ./
deb http://download.opensuse.org/repositories/home:/npreining:/debian-unison/Debian_Unstable ./
/etc/apt/trusted.gpg.d/obs-npreining.asc.
The sources are available at the OBS project debian-unison.
For those interested, I had to backport a few package to Buster to ensure that the builds agree: debhelper (because dh_dwz is buggy in Buster), dh-ocaml, findlib, lablgl, lablgtk2, labltk, and ocaml. These packages are available in the OBS debian-ocaml-backports repository, and are also apt accessible if necessary. I guess you can conjure up the correct line ;-).
That s it. I can now forget about all the differences between versions and happily sync between Buster and sid.
Enjoy.
The following contributors got their Debian Developer accounts in the last two months:
It finally happened
On the 6th of April 2017, I finally took the plunge and applied for Debian Developer status. On 1 August, during DebConf in Montr al, my application was approved. If you re paying attention to the dates you might notice that that was nearly 4 months ago already. I was trying to write a story about how it came to be, but it ended up long. Really long (current draft is around 20 times longer than this entire post). So I decided I d rather do a proper bio page one day and just do a super short version for now so that someone might end up actually reading it.
How it started
In 1999 no wait, I can t start there, as much as I want to, this is a short post, so In 2003, I started doing some contract work for the Shuttleworth Foundation. I was interested in collaborating with them on tuXlabs, a project to get Linux computers into schools. For the few months before that, I was mostly using SuSE Linux. The open source team at the Shuttleworth Foundation all used Debian though, which seemed like a bizarre choice to me since everything in Debian was really old and its boot-floppies installer program kept crashing on my very vanilla computers.
SLUG (Schools Linux Users Group) group photo. SLUG was founded to support the tuXlab schools that ran Linux.
Ubuntu 4.10 default desktop Image from distrowatch
DebConf16 Organisers, Photo by Jurie Senekal.
Next.